The following comment was made by an LLM, it may be inaccurate:

Potential Duplicates Found

PR #7140: Add default variant config per agent
#7140

Why related: This is the primary implementation that the current PR (#7156) is an alternative version of. According to the PR description, #7156 is an alternative implementation for #7138 that includes additional changes not present in #7140, specifically:

• Fallback to agent.variant for message metadata in prompt.ts
• Clarifying comment explaining subagent variant design choice in task.ts

The PR author explicitly states they're "happy to close this if #7140 incorporates these changes," indicating these are addressing the same feature with slightly different approaches.

@CasualDeveloper we can do ur change if u want but I think ti requires updates to both tui AND desktop

Thanks @rekram1-node! I've updated this PR to include both TUI and desktop support:

TUI: local.tsx, prompt/index.tsx, dialog-agent.tsx
Desktop: local.tsx, prompt-input.tsx

Both now have:

• effective() method that returns current() ?? agent.current()?.variant
• Variant display in prompt bar
• Variant shown in agent selector

The prompt.ts change is backend-only and works for all clients automatically.

Ready for review when you have time!

@rekram1-node hi Aiden, thanks for the thorough feedback. Had my Claude address all 12 comments and reduce the scope from 21 → 13 files.

Changes:

• Reverted all UI additions (dialog, session header, app variant display)
• Reverted CLI changes (--variant flag)
• Reverted schema additions (variant in AssistantMessage)
• Reverted Task tool changes (no new model/variant params)
• Refactored LLM resolution to IIFE pattern per feedback
• Removed variant from assistant message creation in prompt.ts

MVP scope retained:

• Agent config schema with variant field
• LLM resolution: user.variant ?? agent.variant
• Prompt bar display (TUI + Desktop)
• Example agents (triage.md, duplicate-pr.md)
• 2 agent variant tests

Ready for another look when you have time.

P.S. I do have a couple points I wanna ask you on how we should handle them:

• With variant removed from AssistantMessage and the session header, there's no way to verify which variant was used within a subagent thread in the TUI:

• With Task tool model/variant overrides removed, orchestrator agents can't dynamically assign reasoning effort per subtask. This could be useful for agents that want to use high-effort for complex tasks and low-effort for simple ones, eg. call a @‍ write agent with model=haiku + variant=low for commit messages/simple comments vs with model=opus + variant=high for complex issue/PR descriptions

With Task tool model/variant overrides removed, orchestrator agents can't dynamically assign reasoning effort per subtask. This could be useful for agents that want to use high-effort for complex tasks and low-effort for simple ones, eg. call a @‍ write agent with model=haiku + variant=low for commit messages/simple comments vs with model=opus + variant=high for complex issue/PR descriptions

I'd prefer not to bloat the task tool for now, it still has optimizations to be ha

@rekram1-node

• re: the task tool changes - understood, will defer.
• re: the session header display - would you want this in a follow-up PR? it involves adding variant back to AssistantMessage schema, storing the resolved variant when message is created, and then displaying it in message metadata display

P.S. included your commit to remove the variant from duplicate-pr.md when I rebased off latest dev just now

/review

lgtm

Hm i don't think it works?

If I select an agent it's not applying my variant

Sorry to jump in, but I think this is what I'd expect (as a user) - the variant in the agent config should be used when I don't set a variant explicitly. In your screenshot it looks like you set high explicitly. Haven't read the code, but am very much looking forward to the feature (thanks for the effort BTW!).

@rekram1-node @mjakl this feature was intended to add variant support for subagents and not main agents, because main agents have always had support for setting variants via ctrl+t

original problem:

• user prefers to use variant=high for main agent and subagent
• main agent has support for variants, so ok
• no support for variants in subagent, so subagent is using default for its model

then i designed the feature so it became:

• user prefers to use variant=high for main agent and subagent
• user can define variant in subagent file
• both main agent and subagent can use variants now

@CasualDeveloper thanks for the clarification, and right, the title of the PR is quite clear on that. Though, I would expect that the variant defined with the agent (no matter whether primary or sub-agent) to be applied, unless I override it with an explicit setting (Ctrl-t), but only for the primary agent, for the sub-agent I'd always expect the variant from the agent definition to be used.

Note: that's just how I hoped it would work, of course there can be reasons for a different mechanic, or simply different taste (esp. whether or not to use the explicit setting for the sub-agent as well).

Being able to set variant on main agent is useful for me too, as I prefer to use high for plan agent and no variant for build agent.

@mjakl
Yes that's is what I had in mind :)

@axsuul
This works for main agents too — the agent's configured variant applies by default. If you've previously set a variant via ctrl+t, that selection persists and takes priority (IMO explicit user choice should override agent defaults by design).

@rekram1-node
Alternative designs:

1. Clear on agent switch — New agent's default applies automatically, user can ctrl+t to override after. Tradeoff: must re-select every time you switch.
2. Store variant per-agent — Each agent remembers its own variant selection independently. Tradeoff: slightly more complex, but avoids the above.

Personally, I feel like this more about about TUI state management for main agents rather than the original issue, so my vote is to leave as-is for MVP and revisit as a follow-up. Happy to take in feedback on this though.